General
As shown in FIG. 1, according to 3G WCDMA (Third Generation Wideband Code Division Multiple Access), in communicating via wireless communication a mobile user equipment (UE) 18 interfaces with an UTRAN (universal mobile telecommunications system (UMTS) terrestrial radio access network) 17, and in particular with a Node B 17a (also sometimes called a base station) of the UTRAN 17, over a so-called Uu interface, which can provide a circuit-switched (CS) or packet-switched (PS) connection between the UE and the UTRAN. The UTRAN Node B in turn communicates with an UTRAN radio network controller (RNC) 17b over a so-called Iub interface, and the RNC communicates with a core network (CN) entity 19, either a mobile switching center (MSC) or a serving GPRS (general packet radio system) support node (SGSN) 19a, over a so-called Iu interface, and also communicates with other RNCs over a so-called Iur interface. The Iu interface is more specifically either a Iu circuit-switched interface IuCS between an UTRAN RNC and an MSC, or a Iu packet-switched interface IuPS between an UTRAN RNC and a SGSN.
A corresponding architecture exists in the case of GSM (Global System for Mobile Communications) providing a GSM RAN 21, in which case the UE/RAN interface is called the Um interface, which thus can provide either a CS connection or a PS connection, and it is GPRS that provides the latter. FIG. 2 shows the logical architecture of GPRS in case of a GSM implementation. In case of GSM, the UE interfaces (over the Um interface) with a Base Station System (BSS) 21a of the GSM RAN 21, which in turn interfaces with a SGSN 22a of a GSM core network 22.
GPRS is thus the service offered by the core network by which a UE is provided a PS connection to another device, via the UTRAN or GSM RAN, for communicating with the other device (such as a device connected to the Internet or just another UE) by the exchange of packets. The overall GPRS logical architecture is defined in 3GPP TS 03.60.
In the PS domain, packet connections are called sessions and they are established and managed by an entity called Session Management (SM). SM is a logical entity having two states, inactive and active. In the inactive state, packet data transfer is not possible and routing information (if it exists) is not valid. In the active state, packet data transfer is possible and all valid routing information is present and defined. The protocol used for packet data transfer during an active session is called Packet Data Protocol (PDP). Many different PDPs are possible, including Internet Protocol (IP) (various versions) and X.25.
The SM handles packet session attributes as so-called contexts, i.e. PDP contexts. A PDP context contains all parameters describing a packet data connection, i.e. a connection between two end point addresses and having a prescribed quality of service (QoS). For example, a PDP context holds information such as allocated IP addresses, connection types and related network element addresses. From the service point of view, one PDP context is set up for one packet switch service with a prescribed QoS class. Thus, for example, web surfing and streaming video over a packet connection each have their own PDP context. (In UMTS, per 3GPP R99, QoS classes include: conversational class, streaming class, interactive class and background class.)
The activation of a PDP context causes the SM to change its state from inactive to active. When a PDP context is activated, a UE and the network are able to establish a bearer for data transfer. When the SM is active (and so when a PDP context exists), the existing PDP context can be changed. To change a PDP context, the UE and the network renegotiate packet session characteristics.
Network layer protocols are intended to be capable of operating over services derived from a wide variety of subnetworks and data links. GPRS supports several network layer protocols providing protocol transparency for the users of the service. Introduction of new network layer protocols to be transferred over GPRS is intended to be possible without any changes to GPRS. Therefore, all functions related to transfer of Network layer Protocol Data Units (N-PDUs) (including control data and possibly user data) are intended to be carried out in a transparent way by GPRS network entities. When GPRS is used over GSM RAN, it is a function of the so-called GPRS SNDCP (subnetwork dependent convergence protocol) layer, a protocol layer using the services of the logical link (protocol) layer (LLC) as shown in FIG. 3, to provide such transparency. Another function of SNDCP is to improve channel efficiency. This requirement is fulfilled using compression techniques.
As shown in FIG. 4, the protocol entities above SNDCP (i.e. using the services of SNDCP) are various commonly used network protocols, or more particularly packet data protocols (such as IPv4 and IPv6). A SNDCP entity performs multiplexing of data coming from different PDPs for transmission using (the service provided by) the LLC layer. The Network Service Access Point Identifier (NSAPI) is an index to the PDP context of the PDP that is using the services provided by SNDCP (a service access point being a conceptual point where a protocol layer offers to an upper protocol layer access to its services). One PDP may have several PDP contexts and NSAPIs. However, it is possible that each allocated NSAPI is used by a different PDP. Each active NSAPI is required to use the services provided by the Service Access Point Identifier (SAPI) in the LLC layer. Several NSAPIs may be associated with the same SAPI.
FIG. 5 illustrates the service access points through which service primitives used for communication between the SNDCP layer and other layers are carried out. The primitives provided by the SNDCP layer (to PDPs) are listed in Table 1.
TABLE 1SNDCP layer service primitives.GenericTypeNameRequestIndicationResponseConfirmParametersSNDCP User (PDP or the SGSN Relay)   SNDCPSN-XIDXX——Requested SNDCPXID ParametersSN-XID——XXNegotiated SNDCPXID Parameters
For example: a SN-XID REQUEST primitive is a request used by the SNDCP user at the initiating entity to deliver the list of requested XID parameters to the peer entity; a SN-XID INDICATION is an indication used by the SNDCP entity to deliver the list of requested XID parameters to the SNDCP user; a SN-XID RESPONSE is a response used by the SNDCP user to deliver the list of negotiated XID parameters to the peer entity; and a SN-XID CONFIRM is a confirmation used by the SNDCP entity to deliver the list of negotiated XID parameters to the SNDCP user.
The SNDCP layer uses the service primitives provided by the SM sublayer and the LLC layer shown in Table 2. SM is specified in 3GPP TS 04.08 and LLC in 3GPP TS 04.64.
TABLE 2Service primitives used by the SNDCP entity.TypeGeneric NameRequestIndicationResponseConfirmParametersSNDCP   LLCLL-RESET—X——TLLILL-ESTABLISHX———TLLI, XID RequestedLL-ESTABLISH—X——TLLI, XID Requested,N201-I, N201-ULL-ESTABLISH——X—TLLI, XID NegotiatedLL-ESTABLISH———XTLLI, XID Negotiated,N201-I, N201-ULL-RELEASEX———TLLI, LocalLL-RELEASE—X——TLLI, CauseLL-RELEASE—XTLLILL-XIDX———TLLI, XID RequestedLL-XID—X——TLLI, XID Requested,N201-I, N201-ULL-XID——X—TLLI, XID NegotiatedLL-XID———XTLLI, XID Negotiated,N201-I, N201-USNDCP   SMSNSM-ACTIVATEX——TLLI, NSAPI, QoS profile,SAPI, Radio PrioritySNSM-ACTIVATE——XTLLI, NSAPISNSM-DEACTIVATE—X——TLLI, NSAPI(s), LLCRelease IndicatorSNSM-DEACTIVATE——X—TLLI, NSAPISNSM-MODIFY—X——TLLI, NSAPI, QoS Profile,SAPI, Radio Priority, SendN-PDU Number, ReceiveN-PDU NumberSNSM-MODIFY——X—TLLI, NSAPI
For example: a LL-XID REQUEST (primitive) is a request used by the SNDCP layer to deliver the requested SNDCP XID parameters to the LLC layer; a LL-XID INDICATION is an indication used by the LLC layer to deliver the requested SNDCP XID parameters to the SNDCP layer; a LL-XID RESPONSE is a response used by the SNDCP layer to deliver the negotiated SNDCP XID parameters to the LLC layer; and a LL-XID CONFIRM is a confirmation used by the LLC layer to deliver the negotiated SNDCP XID parameters to the SNDCP layer.
Also, and more importantly for the present invention, a SNSM-MODIFY INDICATION is an indication used by the SM entity to trigger change of the QoS profile (see 3GPP TS 04.08) for a NSAPI and an indication of the SAPI to be used. It is also used by the SM entity in the SGSN to inform the SNDCP entity that a NSAPI is to be created, together with the (re-)negotiated QoS profile, the SAPI assigned, and, in the MS, the radio priority level to be used by RLC (radio link control)/MAC (media access control). A SNSM-MODIFY RESPONSE is a response used by the SNDCP entity to inform the SM entity that the indicated NSAPI and QoS profile are now in use and the acknowledged peer-to-peer LLC operations for the appropriate SAPIs are established and/or released, if necessary.
Problem(s) Addressed by the Invention
As indicated above, the GPRS protocol architecture consists of various protocol layers. The operation of each layer is specified in detail in corresponding documents, however, the cooperation of these layers is not yet well specified. One problem is the cooperation between the SNDC layer and the LLC. As indicated above, SNDC handles PDP contexts and each context has a NSAPI number; there can be up to eleven parallel PDP contexts. LLC handles logical links, and each logical link has its own SAPI number; there can be up to four parallel logical links. As mentioned, one NSAPI can be mapped to only one SAPI at any one time, i.e. one NSAPI corresponds to only one NSAPI, but several NSAPIs can be mapped to the same SAPI, i.e. one SAPI may correspond to several NSAPIs. The network controls the mapping between contexts of SAPIs and NSAPIs and it is possible for the network to change the mapping on the fly. PDP contexts having different QoS profiles must be placed in separate SAPIs. SNDC level compression algorithms are negotiated using LLC level procedures (using so-called XID negotiation).
3GPP LLC specification 04.64 says that LLC messages received on a SAPI not mapped to a PDP context can be discarded. However, SNDC specification (04.65) says that after a context modification procedure, the network should in certain cases start XID (context identifier) negotiation and/or a logical link disconnection procedure using the old SAPI. This causes a conflicting situation, i.e. the network sends LLC messages that the mobile side is allowed to discard. Depending on the network implementation, this can cause a long break in the data transfer or even PDP context deactivation.
The easiest solution is to keep all LLC links active at all times. However, this has a negative memory consumption effect since the data structures need to be reserved for all SAPIs. Another solution is to not really support four parallel independent LLC links. This solution is fine if you support one PDP context only, or if the network always maps all NSAPIs to one SAPI, but it does not work when you have several contexts that need separate SAPIs (because of different QoS). A third alternative is to allow mapping of one NSAPI to two SAPIs until LLC link disconnection procedure and/or XID negotiation for the old SAPI has taken place. However, it is possible that the network does not perform the link disconnection procedure or XID negotiation at all, and in that case the old SAPI would be left active.
What is needed is a procedure (protocol) according to which in case of a mobile receiving a PDP context modification message, the mobile does not discard at least some of the LLC messages sent by the network, at least not for a time deemed long enough that no significant break in data transfer is likely, nor is PDP context deactivation.